Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[rules_ios] Re-enable cpp rules #3

Merged
merged 1 commit into from
Apr 25, 2023
Merged

Conversation

nataliejameson
Copy link
Contributor

This was accidentally disabled. It is required for glog, so turn this
back on so that .cc/.cpp sources and their .a files are properly
propagated.

Tested by doing a build with this change off of main

This was accidentally disabled. It is required for glog, so turn this
back on so that .cc/.cpp sources and their .a files are properly
propagated.

Tested by doing a build with this change off of main
@nataliejameson nataliejameson requested review from Osmose, stevenpetryk and a team April 18, 2023 17:51
Copy link
Member

@denbeigh2000 denbeigh2000 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

seems fine to me, but you probably wanna update that comment

@@ -1018,7 +1018,7 @@ def apple_library(name, library_tools = {}, export_private_headers = True, names
_append_headermap_copts(swift_angle_bracket_hmap_name, "-I", additional_objc_copts, additional_swift_copts, additional_cc_copts)

# Note: this line is intentionally disabled
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: this isn't intentionally disabled anymore

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't remove that line, because it's still there upstream where they've re-enabled cpp as well 😂

https://github.com/bazel-ios/rules_ios/blob/master/rules/library.bzl#L1021

@nataliejameson nataliejameson merged commit 01a939d into discord Apr 25, 2023
nataliejameson pushed a commit that referenced this pull request Apr 20, 2024
nataliejameson pushed a commit that referenced this pull request Apr 20, 2024
…ansitive_deps (#3) (#570)" (#715)

This reverts commit 6f11291 (bazel-ios/rules_ios#570). This fixes bazel-ios/rules_ios#712 and is confirmed in bazel-ios/rules_ios#713 (which can be merged after this is done since I don't have repo branch push access).
nataliejameson added a commit that referenced this pull request Apr 20, 2024
Add an `apple_static_library` that lets us map source files to arbitrary
relative include paths by creating a link tree, and adding that link
tree to the deps of a main library.

This also uses apple_library instead of apple_framework as the framework
is frankly unnecessary for what we're trying to build for third party
deps.

Test Plan: Ported fmt locally to use this, and ran `clyde ios build`

Tasks:

https://app.asana.com/0/1203960884932166/1204190072048691
https://app.asana.com/0/1203960884932166/1204190072362093

[transitions] Do not remove cpus from configured target graph (#2)

Upstream converts ios_multi_cpus to a single value. rules_pods does
not. So when rules_pods objc_library rules depend on rules_ios rules,
they are considered different configurations, and we end up splitting
the configured target graph into two configurations. When swift, objc,
etc try to link in all objc_libraries later in the build, they then
try to link the same library twice, because the configured nodes are
duplicated, and we run into duplicate symbol, module redefinition, etc
errors.

In theory, this could be reverted once the rules_ios migration is
complete, but for our use case, it should not hurt anything being
present. This logic, also, only affects our opt builds that build
for multiple cpus. The development builds are unaffected.

[rules_ios] Re-enable cpp rules (#3)

This was accidentally disabled. It is required for glog, so turn this
back on so that .cc/.cpp sources and their .a files are properly
propagated.

Tested by doing a build with this change off of main

[rules_ios] Use -idirafter instead of -I (#4)

NOTE: that this may cause issues for libraries that anticipate the `-I.` behavior and do something like `#include "Foo.h"` when there are multiple "Foo.h" in libs in its dependencies. In those cases, `-I.` can be added to its copts explicitly.

There are some places where using -I can actually cause problems with
system header collisions. Notably, fmt has a "locale.h" file. Without
this change, you can end up with a chain that is:

"fmt/locale.h" -> <locale> -> <clocale> -> <locale.h> -> failure,
because -I causes fmt/locale.h to be searched (I believe due to the
entries in the headermap being -I) before system paths.

See https://gcc.gnu.org/onlinedocs/gcc/Directory-Options.html for
resolution order

[rules_ios] Allow rewriting header paths for frameworks and libraries (#5)

This allows us to pick a different relative include path for header
files. This is needed because some third party dependencies have e.g.
colliding base filenames (folly has multiple Core.h, e.g.), or included
files do relative includes (kv-storage includes
"kv-storage/api/Core.h"), and with the current approach taken by
apple_framework of flattening the headers out, that path doesn't
actually exist in the Headers or PrivateHeaders directories of the
.framework file.

This patch does a few things:
- Adds an extra argument "header_mapping". This is how users define
where public/private headers should be accessible. If not specified, or
a header is not in this mapping, then the basename of the header is
used. (e.g. kv-storage.framework/Headers/Core.h)
- Updates the hmapbuild binary so that we can specify these destinations
in the .hmap files
 - Updates the umbrella header to use these destinations
- Updates apple_framework/apple_library to thread these mappings
through.

Tested on a WIP branch (annie/native-versions-ios), and we seemed to get
past the #include failures, and onto errors in their code itself. Will
also test this with the flipper-folly migration locally.

https://app.asana.com/0/1203960884932166/1204190072362095
https://app.asana.com/0/1203960884932166/1204190072362093

[rules_ios] Make modulemaps have '[system]', fix static_library deps (#6)

- There was an ordering issue with apple_static_library where it didn't
include the symlink map in the deps for the apple_library call. Make
sure to route it through.
- When changing over to cocoapods bazel, we modularize a lot of things,
which causes a lot of extra warnings to show up from third party
packages. We're not really in charge of maintaining their code, so just
add the "[system]" tag to the modulemap file. This makes the headers get
included as if they were included through -isystem, not -I

[rules_ios] Export as system_includes (#7)

For system / 3rd party libraries, export the symlink dir as -isystem,
not -I.

[rules_ios] Add objc_public_headers (#9)

Add an `objc_public_headers` attribute to apple_* rules. This changes
the umbrella header, if set, such that it includes all public_headers
headers when compiled against c++, and only a subset of headers
(objc_public_headers) when compiled against objective c.

The main problem this is solving is that we have a main module map for
each library. When trying to import *anything* from the framework, it
loads the entire module map and every include in the umbrella header. If
you put c++-only headers in it, it will try to interpret those without
c++ support if you try to include the .h from a .m file. This allows us
to have headers that mix (obj)c++ and objc in a single framework. It
should also allow us to drop some of the -objc rules we've had to
clunkily build out.

[rules_ios] Expose cc_headers_symlinks, add a helper function for headers (#10)

Expose cc_headers_symlinks so that we can use it in a refactor of
React-Core and ReactCommon. Also expose a helper function for use by
ReactCommon

[rules_ios] Add more entitlement errors (#12)

If there are keys that are in the .entitlements file that are missing
from the provisioning profile, this normally results in an error.
However, this is a manually specified list. These storekit ones bit us
recently, so add the storekit ones, and then just pull in the list from
main

(https://github.com/bazelbuild/rules_apple/blob/cc1e5b17d0bf16a74c74f9fb3e2940d9c97c12da/tools/plisttool/plisttool.py#L295-L314)

[rules_ios] Add more configurability to headers_mapping (#11)

When this just takes a dictionary, it requires us to do a lot more
boilerplate work to first construct that dictionary. Add a couple of
helpers for the common use cases that are in repo.

[rules_apple] add upstream filesystem patches (#13)

this adds [this
commit](bazelbuild/rules_apple@306e300)
to address this error when copying results files across filesystem
boundaries.

[rules_apple] Add support for xcprivacy manifests in extensions (#14)

Bringing a change in from upstream of rules_apple to support adding
privacy manifests for our extensions
bazelbuild/rules_apple@e9159fa
nataliejameson added a commit that referenced this pull request Aug 13, 2024
Add an `apple_static_library` that lets us map source files to arbitrary
relative include paths by creating a link tree, and adding that link
tree to the deps of a main library.

This also uses apple_library instead of apple_framework as the framework
is frankly unnecessary for what we're trying to build for third party
deps.

Test Plan: Ported fmt locally to use this, and ran `clyde ios build`

Tasks:

https://app.asana.com/0/1203960884932166/1204190072048691
https://app.asana.com/0/1203960884932166/1204190072362093

[transitions] Do not remove cpus from configured target graph (#2)

Upstream converts ios_multi_cpus to a single value. rules_pods does
not. So when rules_pods objc_library rules depend on rules_ios rules,
they are considered different configurations, and we end up splitting
the configured target graph into two configurations. When swift, objc,
etc try to link in all objc_libraries later in the build, they then
try to link the same library twice, because the configured nodes are
duplicated, and we run into duplicate symbol, module redefinition, etc
errors.

In theory, this could be reverted once the rules_ios migration is
complete, but for our use case, it should not hurt anything being
present. This logic, also, only affects our opt builds that build
for multiple cpus. The development builds are unaffected.

[rules_ios] Re-enable cpp rules (#3)

This was accidentally disabled. It is required for glog, so turn this
back on so that .cc/.cpp sources and their .a files are properly
propagated.

Tested by doing a build with this change off of main

[rules_ios] Use -idirafter instead of -I (#4)

NOTE: that this may cause issues for libraries that anticipate the `-I.` behavior and do something like `#include "Foo.h"` when there are multiple "Foo.h" in libs in its dependencies. In those cases, `-I.` can be added to its copts explicitly.

There are some places where using -I can actually cause problems with
system header collisions. Notably, fmt has a "locale.h" file. Without
this change, you can end up with a chain that is:

"fmt/locale.h" -> <locale> -> <clocale> -> <locale.h> -> failure,
because -I causes fmt/locale.h to be searched (I believe due to the
entries in the headermap being -I) before system paths.

See https://gcc.gnu.org/onlinedocs/gcc/Directory-Options.html for
resolution order

[rules_ios] Allow rewriting header paths for frameworks and libraries (#5)

This allows us to pick a different relative include path for header
files. This is needed because some third party dependencies have e.g.
colliding base filenames (folly has multiple Core.h, e.g.), or included
files do relative includes (kv-storage includes
"kv-storage/api/Core.h"), and with the current approach taken by
apple_framework of flattening the headers out, that path doesn't
actually exist in the Headers or PrivateHeaders directories of the
.framework file.

This patch does a few things:
- Adds an extra argument "header_mapping". This is how users define
where public/private headers should be accessible. If not specified, or
a header is not in this mapping, then the basename of the header is
used. (e.g. kv-storage.framework/Headers/Core.h)
- Updates the hmapbuild binary so that we can specify these destinations
in the .hmap files
 - Updates the umbrella header to use these destinations
- Updates apple_framework/apple_library to thread these mappings
through.

Tested on a WIP branch (annie/native-versions-ios), and we seemed to get
past the #include failures, and onto errors in their code itself. Will
also test this with the flipper-folly migration locally.

https://app.asana.com/0/1203960884932166/1204190072362095
https://app.asana.com/0/1203960884932166/1204190072362093

[rules_ios] Make modulemaps have '[system]', fix static_library deps (#6)

- There was an ordering issue with apple_static_library where it didn't
include the symlink map in the deps for the apple_library call. Make
sure to route it through.
- When changing over to cocoapods bazel, we modularize a lot of things,
which causes a lot of extra warnings to show up from third party
packages. We're not really in charge of maintaining their code, so just
add the "[system]" tag to the modulemap file. This makes the headers get
included as if they were included through -isystem, not -I

[rules_ios] Export as system_includes (#7)

For system / 3rd party libraries, export the symlink dir as -isystem,
not -I.

[rules_ios] Add objc_public_headers (#9)

Add an `objc_public_headers` attribute to apple_* rules. This changes
the umbrella header, if set, such that it includes all public_headers
headers when compiled against c++, and only a subset of headers
(objc_public_headers) when compiled against objective c.

The main problem this is solving is that we have a main module map for
each library. When trying to import *anything* from the framework, it
loads the entire module map and every include in the umbrella header. If
you put c++-only headers in it, it will try to interpret those without
c++ support if you try to include the .h from a .m file. This allows us
to have headers that mix (obj)c++ and objc in a single framework. It
should also allow us to drop some of the -objc rules we've had to
clunkily build out.

[rules_ios] Expose cc_headers_symlinks, add a helper function for headers (#10)

Expose cc_headers_symlinks so that we can use it in a refactor of
React-Core and ReactCommon. Also expose a helper function for use by
ReactCommon

[rules_ios] Add more entitlement errors (#12)

If there are keys that are in the .entitlements file that are missing
from the provisioning profile, this normally results in an error.
However, this is a manually specified list. These storekit ones bit us
recently, so add the storekit ones, and then just pull in the list from
main

(https://github.com/bazelbuild/rules_apple/blob/cc1e5b17d0bf16a74c74f9fb3e2940d9c97c12da/tools/plisttool/plisttool.py#L295-L314)

[rules_ios] Add more configurability to headers_mapping (#11)

When this just takes a dictionary, it requires us to do a lot more
boilerplate work to first construct that dictionary. Add a couple of
helpers for the common use cases that are in repo.

[rules_apple] add upstream filesystem patches (#13)

this adds [this
commit](bazelbuild/rules_apple@306e300)
to address this error when copying results files across filesystem
boundaries.

[rules_apple] Add support for xcprivacy manifests in extensions (#14)

Bringing a change in from upstream of rules_apple to support adding
privacy manifests for our extensions
bazelbuild/rules_apple@e9159fa
nataliejameson added a commit that referenced this pull request Aug 13, 2024
…anup custom patches (#15)

This does a few things:

- Squashes our existing changes since our last divergence point with
main. I only did this because it was easier since we had a lot of
iteration on our interim PRs that isn't strictly necessary or relevant
anymore.
- Removes some patches / patching logic where we had backported
functionality from rules_apple. We do not need to patch rules_apple
right now.
- Rebases us onto upstream version 4.8.2 of rules_ios
- Removes apple_common.new_objc_provider in _cc_headers_symlinks_impl.
In the new rules_ios, that being present causes it to attempt to infer
and build a swift modulemap, which we don't need.
- Removes a change we had made to CPU configuration to support both
cocoapods and podtobuild at the same time. We're back on the upstream
configuration.

At the end, the major changes we have vs upstream are:

- Adding static_framework rule
- Headermap rewriting
- Changing some rules from -I to -idirafter
- Mark a few things as "system" so we don't see their errors in our
builds.

The original commits were:

2e4ed21 (origin/discord, origin/HEAD, discord) [rules_apple] Add support
for xcprivacy manifests in extensions (#14)
86b8d2d [rules_apple] add upstream filesystem patches (#13)
0add154 [rules_ios] Add more configurability to headers_mapping (#11)
a6c59d1 [rules_ios] Add more entitlement errors (#12)
2699bd3 [rules_ios] Expose cc_headers_symlinks, add a helper function
for headers (#10)
c494ff2 [rules_ios] Add objc_public_headers (#9)
7d8db25 [rules_ios] Export as system_includes (#7)
28ed123 [rules_ios] Make modulemaps have '[system]', fix static_library
deps (#6)
4340c91 [rules_ios] Allow rewriting header paths for frameworks and
libraries (#5)
1fc624a [rules_ios] Use -idirafter instead of -I (#4)
01a939d [rules_ios] Re-enable cpp rules (#3)
238256a [transitions] Do not remove cpus from configured target graph
(#2)
429e3f0 [rules_ios] Add static library variant to allow rewriting
headers (#1)

---------

Co-authored-by: Thiago Cruz <thiago.hmcruz@gmail.com>
Co-authored-by: Luis Padron <lpadron@squareup.com>
nataliejameson pushed a commit that referenced this pull request Aug 13, 2024
nataliejameson pushed a commit that referenced this pull request Aug 13, 2024
…ansitive_deps (#3) (#570)" (#715)

This reverts commit 6f11291 (bazel-ios/rules_ios#570). This fixes bazel-ios/rules_ios#712 and is confirmed in bazel-ios/rules_ios#713 (which can be merged after this is done since I don't have repo branch push access).
nataliejameson added a commit that referenced this pull request Aug 13, 2024
Add an `apple_static_library` that lets us map source files to arbitrary
relative include paths by creating a link tree, and adding that link
tree to the deps of a main library.

This also uses apple_library instead of apple_framework as the framework
is frankly unnecessary for what we're trying to build for third party
deps.

Test Plan: Ported fmt locally to use this, and ran `clyde ios build`

Tasks:

https://app.asana.com/0/1203960884932166/1204190072048691
https://app.asana.com/0/1203960884932166/1204190072362093

[transitions] Do not remove cpus from configured target graph (#2)

Upstream converts ios_multi_cpus to a single value. rules_pods does
not. So when rules_pods objc_library rules depend on rules_ios rules,
they are considered different configurations, and we end up splitting
the configured target graph into two configurations. When swift, objc,
etc try to link in all objc_libraries later in the build, they then
try to link the same library twice, because the configured nodes are
duplicated, and we run into duplicate symbol, module redefinition, etc
errors.

In theory, this could be reverted once the rules_ios migration is
complete, but for our use case, it should not hurt anything being
present. This logic, also, only affects our opt builds that build
for multiple cpus. The development builds are unaffected.

[rules_ios] Re-enable cpp rules (#3)

This was accidentally disabled. It is required for glog, so turn this
back on so that .cc/.cpp sources and their .a files are properly
propagated.

Tested by doing a build with this change off of main

[rules_ios] Use -idirafter instead of -I (#4)

NOTE: that this may cause issues for libraries that anticipate the `-I.` behavior and do something like `#include "Foo.h"` when there are multiple "Foo.h" in libs in its dependencies. In those cases, `-I.` can be added to its copts explicitly.

There are some places where using -I can actually cause problems with
system header collisions. Notably, fmt has a "locale.h" file. Without
this change, you can end up with a chain that is:

"fmt/locale.h" -> <locale> -> <clocale> -> <locale.h> -> failure,
because -I causes fmt/locale.h to be searched (I believe due to the
entries in the headermap being -I) before system paths.

See https://gcc.gnu.org/onlinedocs/gcc/Directory-Options.html for
resolution order

[rules_ios] Allow rewriting header paths for frameworks and libraries (#5)

This allows us to pick a different relative include path for header
files. This is needed because some third party dependencies have e.g.
colliding base filenames (folly has multiple Core.h, e.g.), or included
files do relative includes (kv-storage includes
"kv-storage/api/Core.h"), and with the current approach taken by
apple_framework of flattening the headers out, that path doesn't
actually exist in the Headers or PrivateHeaders directories of the
.framework file.

This patch does a few things:
- Adds an extra argument "header_mapping". This is how users define
where public/private headers should be accessible. If not specified, or
a header is not in this mapping, then the basename of the header is
used. (e.g. kv-storage.framework/Headers/Core.h)
- Updates the hmapbuild binary so that we can specify these destinations
in the .hmap files
 - Updates the umbrella header to use these destinations
- Updates apple_framework/apple_library to thread these mappings
through.

Tested on a WIP branch (annie/native-versions-ios), and we seemed to get
past the #include failures, and onto errors in their code itself. Will
also test this with the flipper-folly migration locally.

https://app.asana.com/0/1203960884932166/1204190072362095
https://app.asana.com/0/1203960884932166/1204190072362093

[rules_ios] Make modulemaps have '[system]', fix static_library deps (#6)

- There was an ordering issue with apple_static_library where it didn't
include the symlink map in the deps for the apple_library call. Make
sure to route it through.
- When changing over to cocoapods bazel, we modularize a lot of things,
which causes a lot of extra warnings to show up from third party
packages. We're not really in charge of maintaining their code, so just
add the "[system]" tag to the modulemap file. This makes the headers get
included as if they were included through -isystem, not -I

[rules_ios] Export as system_includes (#7)

For system / 3rd party libraries, export the symlink dir as -isystem,
not -I.

[rules_ios] Add objc_public_headers (#9)

Add an `objc_public_headers` attribute to apple_* rules. This changes
the umbrella header, if set, such that it includes all public_headers
headers when compiled against c++, and only a subset of headers
(objc_public_headers) when compiled against objective c.

The main problem this is solving is that we have a main module map for
each library. When trying to import *anything* from the framework, it
loads the entire module map and every include in the umbrella header. If
you put c++-only headers in it, it will try to interpret those without
c++ support if you try to include the .h from a .m file. This allows us
to have headers that mix (obj)c++ and objc in a single framework. It
should also allow us to drop some of the -objc rules we've had to
clunkily build out.

[rules_ios] Expose cc_headers_symlinks, add a helper function for headers (#10)

Expose cc_headers_symlinks so that we can use it in a refactor of
React-Core and ReactCommon. Also expose a helper function for use by
ReactCommon

[rules_ios] Add more entitlement errors (#12)

If there are keys that are in the .entitlements file that are missing
from the provisioning profile, this normally results in an error.
However, this is a manually specified list. These storekit ones bit us
recently, so add the storekit ones, and then just pull in the list from
main

(https://github.com/bazelbuild/rules_apple/blob/cc1e5b17d0bf16a74c74f9fb3e2940d9c97c12da/tools/plisttool/plisttool.py#L295-L314)

[rules_ios] Add more configurability to headers_mapping (#11)

When this just takes a dictionary, it requires us to do a lot more
boilerplate work to first construct that dictionary. Add a couple of
helpers for the common use cases that are in repo.

[rules_apple] add upstream filesystem patches (#13)

this adds [this
commit](bazelbuild/rules_apple@306e300)
to address this error when copying results files across filesystem
boundaries.

[rules_apple] Add support for xcprivacy manifests in extensions (#14)

Bringing a change in from upstream of rules_apple to support adding
privacy manifests for our extensions
bazelbuild/rules_apple@e9159fa
nataliejameson added a commit that referenced this pull request Aug 13, 2024
Add an `apple_static_library` that lets us map source files to arbitrary
relative include paths by creating a link tree, and adding that link
tree to the deps of a main library.

This also uses apple_library instead of apple_framework as the framework
is frankly unnecessary for what we're trying to build for third party
deps.

Test Plan: Ported fmt locally to use this, and ran `clyde ios build`

Tasks:

https://app.asana.com/0/1203960884932166/1204190072048691
https://app.asana.com/0/1203960884932166/1204190072362093

[transitions] Do not remove cpus from configured target graph (#2)

Upstream converts ios_multi_cpus to a single value. rules_pods does
not. So when rules_pods objc_library rules depend on rules_ios rules,
they are considered different configurations, and we end up splitting
the configured target graph into two configurations. When swift, objc,
etc try to link in all objc_libraries later in the build, they then
try to link the same library twice, because the configured nodes are
duplicated, and we run into duplicate symbol, module redefinition, etc
errors.

In theory, this could be reverted once the rules_ios migration is
complete, but for our use case, it should not hurt anything being
present. This logic, also, only affects our opt builds that build
for multiple cpus. The development builds are unaffected.

[rules_ios] Re-enable cpp rules (#3)

This was accidentally disabled. It is required for glog, so turn this
back on so that .cc/.cpp sources and their .a files are properly
propagated.

Tested by doing a build with this change off of main

[rules_ios] Use -idirafter instead of -I (#4)

NOTE: that this may cause issues for libraries that anticipate the `-I.` behavior and do something like `#include "Foo.h"` when there are multiple "Foo.h" in libs in its dependencies. In those cases, `-I.` can be added to its copts explicitly.

There are some places where using -I can actually cause problems with
system header collisions. Notably, fmt has a "locale.h" file. Without
this change, you can end up with a chain that is:

"fmt/locale.h" -> <locale> -> <clocale> -> <locale.h> -> failure,
because -I causes fmt/locale.h to be searched (I believe due to the
entries in the headermap being -I) before system paths.

See https://gcc.gnu.org/onlinedocs/gcc/Directory-Options.html for
resolution order

[rules_ios] Allow rewriting header paths for frameworks and libraries (#5)

This allows us to pick a different relative include path for header
files. This is needed because some third party dependencies have e.g.
colliding base filenames (folly has multiple Core.h, e.g.), or included
files do relative includes (kv-storage includes
"kv-storage/api/Core.h"), and with the current approach taken by
apple_framework of flattening the headers out, that path doesn't
actually exist in the Headers or PrivateHeaders directories of the
.framework file.

This patch does a few things:
- Adds an extra argument "header_mapping". This is how users define
where public/private headers should be accessible. If not specified, or
a header is not in this mapping, then the basename of the header is
used. (e.g. kv-storage.framework/Headers/Core.h)
- Updates the hmapbuild binary so that we can specify these destinations
in the .hmap files
 - Updates the umbrella header to use these destinations
- Updates apple_framework/apple_library to thread these mappings
through.

Tested on a WIP branch (annie/native-versions-ios), and we seemed to get
past the #include failures, and onto errors in their code itself. Will
also test this with the flipper-folly migration locally.

https://app.asana.com/0/1203960884932166/1204190072362095
https://app.asana.com/0/1203960884932166/1204190072362093

[rules_ios] Make modulemaps have '[system]', fix static_library deps (#6)

- There was an ordering issue with apple_static_library where it didn't
include the symlink map in the deps for the apple_library call. Make
sure to route it through.
- When changing over to cocoapods bazel, we modularize a lot of things,
which causes a lot of extra warnings to show up from third party
packages. We're not really in charge of maintaining their code, so just
add the "[system]" tag to the modulemap file. This makes the headers get
included as if they were included through -isystem, not -I

[rules_ios] Export as system_includes (#7)

For system / 3rd party libraries, export the symlink dir as -isystem,
not -I.

[rules_ios] Add objc_public_headers (#9)

Add an `objc_public_headers` attribute to apple_* rules. This changes
the umbrella header, if set, such that it includes all public_headers
headers when compiled against c++, and only a subset of headers
(objc_public_headers) when compiled against objective c.

The main problem this is solving is that we have a main module map for
each library. When trying to import *anything* from the framework, it
loads the entire module map and every include in the umbrella header. If
you put c++-only headers in it, it will try to interpret those without
c++ support if you try to include the .h from a .m file. This allows us
to have headers that mix (obj)c++ and objc in a single framework. It
should also allow us to drop some of the -objc rules we've had to
clunkily build out.

[rules_ios] Expose cc_headers_symlinks, add a helper function for headers (#10)

Expose cc_headers_symlinks so that we can use it in a refactor of
React-Core and ReactCommon. Also expose a helper function for use by
ReactCommon

[rules_ios] Add more entitlement errors (#12)

If there are keys that are in the .entitlements file that are missing
from the provisioning profile, this normally results in an error.
However, this is a manually specified list. These storekit ones bit us
recently, so add the storekit ones, and then just pull in the list from
main

(https://github.com/bazelbuild/rules_apple/blob/cc1e5b17d0bf16a74c74f9fb3e2940d9c97c12da/tools/plisttool/plisttool.py#L295-L314)

[rules_ios] Add more configurability to headers_mapping (#11)

When this just takes a dictionary, it requires us to do a lot more
boilerplate work to first construct that dictionary. Add a couple of
helpers for the common use cases that are in repo.

[rules_apple] add upstream filesystem patches (#13)

this adds [this
commit](bazelbuild/rules_apple@306e300)
to address this error when copying results files across filesystem
boundaries.

[rules_apple] Add support for xcprivacy manifests in extensions (#14)

Bringing a change in from upstream of rules_apple to support adding
privacy manifests for our extensions
bazelbuild/rules_apple@e9159fa
nataliejameson added a commit that referenced this pull request Aug 13, 2024
…anup custom patches (#16)

Re-applying #15 

This does a few things:

- Squashes our existing changes since our last divergence point with
main. I only did this because it was easier since we had a lot of
iteration on our interim PRs that isn't strictly necessary or relevant
anymore.
- Removes some patches / patching logic where we had backported
functionality from rules_apple. We do not need to patch rules_apple
right now.
- Rebases us onto upstream version 4.8.2 of rules_ios
- Removes apple_common.new_objc_provider in _cc_headers_symlinks_impl.
In the new rules_ios, that being present causes it to attempt to infer
and build a swift modulemap, which we don't need.
- Removes a change we had made to CPU configuration to support both
cocoapods and podtobuild at the same time. We're back on the upstream
configuration.

At the end, the major changes we have vs upstream are:

- Adding static_framework rule
- Headermap rewriting
- Changing some rules from -I to -idirafter
- Mark a few things as "system" so we don't see their errors in our
builds.

The original commits were:

2e4ed21 (origin/discord, origin/HEAD, discord) [rules_apple] Add support
for xcprivacy manifests in extensions (#14)
86b8d2d [rules_apple] add upstream filesystem patches (#13)
0add154 [rules_ios] Add more configurability to headers_mapping (#11)
a6c59d1 [rules_ios] Add more entitlement errors (#12)
2699bd3 [rules_ios] Expose cc_headers_symlinks, add a helper function
for headers (#10)
c494ff2 [rules_ios] Add objc_public_headers (#9)
7d8db25 [rules_ios] Export as system_includes (#7)
28ed123 [rules_ios] Make modulemaps have '[system]', fix static_library
deps (#6)
4340c91 [rules_ios] Allow rewriting header paths for frameworks and
libraries (#5)
1fc624a [rules_ios] Use -idirafter instead of -I (#4)
01a939d [rules_ios] Re-enable cpp rules (#3)
238256a [transitions] Do not remove cpus from configured target graph
(#2)
429e3f0 [rules_ios] Add static library variant to allow rewriting
headers (#1)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants